core: Add documentation for ostree_commit_get_timestamp()

Working on some rpm-ostree bits and was going to pass
this to the `chrono` crate and I forgot the format, went
to look at the docs.  Oops.

Merge pull request #2133 from jlebon/pr/ci-commitmessage

ci: Import latest ci-commitmessage-submodules from rpm-ostree

Merge pull request #2135 from mwleeds/test-symbols-check-for-example

tests: Check that example symbol isn't released

tests: Check that example symbol isn't released

For the motivation for this see #2132.

Merge pull request #2132 from cgwalters/remove-unused-symbol

libostree-devel.sym: Remove nonexistent stub symbol

ci: Remove libpaprci/ directory

And move everything that was in it directly in `ci/`. There's a bunch
more cleanups here that we need to do (and more changes to upstream from
the rpm-ostree copies of this).

Merge pull request #2134 from d4s/wip/d4s/fix_abort_on_verify

Fix abort on verify

libostree-devel.sym: Remove nonexistent stub symbol

This should have been removed when we added symbols to this list.

sign/ed25519: fix return value if no correct keys in file

Fix the return value if file doesn't contains correct public key(s).

Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

sign/ed25519: fix the abort in case of incorrect public key

We need to check the size of public key before trying to use it.

Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

ci: Import latest ci-commitmessage-submodules from rpm-ostree

Especially for https://github.com/coreos/rpm-ostree/pull/2079.

Merge pull request #2130 from jlebon/pr/bump-libglnx

libglnx: Bump to latest

libglnx: Bump to latest

For `copy_file_range` fix:

https://gitlab.gnome.org/GNOME/libglnx/-/merge_requests/18

Update submodule: libglnx

Merge pull request #2129 from cgwalters/ed25519-errors

sign/ed25519: Output failed signatures in error message

sign/ed25519: Output failed signatures in error message

To aid debuggability, when we find a commit that isn't signed
by our expected key, output a specific error message with the
key.

(And then add code to switch to just printing the count beyond 3
 because the test suite injects 100 keys and hopefully no one
 ever actually does that)

Merge pull request #2128 from cgwalters/verify-pre-signed

tests: Add a pre-signed-pull.sh test

tests: Add a pre-signed-pull.sh test

I'm thinking about adding an implementation of ed25519 signatures
with OpenSSL (so we can ship the feature with Fedora CoreOS
without requiring an additional library) and in preparation for
that it's essential that we validate that libsodium-generated
signatures and OpenSSL-generated signatures are compatible.

I don't know if they are yet actually, but the goal of this
new test is to add a pre-generated repository with a signed
commit generated by libsodium.

This will catch if e.g. there's ever a change in libsodium,
or if existing libsodium implementation versions (e.g. the
one in Debian) might differ from what we ship here.

Merge pull request #2094 from zpiotr/patch-1

Changing link to file about contributing, in readme.

README.md: Fix link to CONTRIBUTING.md

We should link to the target and not the symlink.

Merge pull request #2121 from cgwalters/arch-key

core: Add OSTREE_COMMIT_META_KEY_ARCH

Merge pull request #2126 from agners/improve-ostree-checkout-man

Improve checkout man page

man/checkout: document missing options

Document missing options in the ostree checkout man page.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

checkout: use FILE as option argument string for --skip-list

Align with --from-file and use 'FILE' instead of 'PATH' as option
argument string. No functional change, this is only cosmetics.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

man/checkout: fix short name option of --user-mode

The short name option of --user-mode is -U.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

core: Add OSTREE_COMMIT_META_KEY_ARCHITECTURE

Add a standard key for this.  We actually had a case in OpenShift
builds recently where a `ppc64le` image was pushed over an `x86_64`
one and this started failing at runtime with a not immediately
obvious error.

I'll probably end up changing rpm-ostree at least to use
the RPM architecture for this key and fail if it doesn't match
the booted value.

Possibly that should live in ostree but it would involve adding
architecture schema here, which gets into a big mess.  Let's
just standardize the key.

xref https://github.com/coreos/coreos-assembler/commit/e02ef2683d688607e7b5ad9ea6a0c00c50a682a5

Merge pull request #2123 from cgwalters/all-your-base-have-arguments

commit: Note in help that --base takes an argument

commit: Note in help that --base takes an argument

I was trying to use this in some testing work and was confused for a minute.

Merge pull request #2122 from cgwalters/testrs-webserver

tests/rust: Extract a with_webserver_in helper wrapper

tests/rust: Extract a with_webserver_in helper wrapper

It's much cleaner if the Tokio stuff stays in `test.rs`, and
easier to write tests if the function is synchronous.

Prep for further tests.

Merge pull request #2048 from cgwalters/rust-cmdspec-tests

Add new Rust-based tests

Merge pull request #2119 from cgwalters/bumpsplit-rustfmt

bupsplit: rustfmt(*)

bupsplit: rustfmt(*)

Let's use the standard rustfmt style.
Also remove unused parenthesis which rust-analyzer was complaining
about.

Also add a `.gitignore`.

Merge pull request #2118 from cgwalters/error-prefix-parsing

lib: Add error prefixing with specific object when loading

pull: Add error prefixing with specific object when parsing

One OpenShift user saw this from rpm-ostree:
```
client(id:cli dbus:1.583 unit:machine-config-daemon-host.service uid:0) added; new total=1
Initiated txn UpdateDeployment for client(id:cli dbus:1.583 unit:machine-config-daemon-host.service uid:0): /org/projectatomic/rpmostree1/rhcos
Txn UpdateDeployment on /org/projectatomic/rpmostree1/rhcos failed: File header size 4294967295 exceeds size 0
```

which isn't very helpful.  Let's add some error
prefixing here which would at least tell us which
object was corrupted.

Merge pull request #2117 from cgwalters/pull-signapi-default-explicit

remote-add: Default to explicit sign-verify backends

remote-add: Default to explicit sign-verify backends

In https://github.com/ostreedev/ostree/pull/2092/commits/588f42e8c64183dfa1fbaa08cc92c46b691b23c4
we added a way to add keys for sign types when doing
a `remote add`, and in https://github.com/ostreedev/ostree/pull/2105
we extended `sign-verify` to support *limiting* to an explicit
set.

This PR changes the *default* for `remote add` to combine
the two - when providing an explicit `--sign-verify=type`,
we now limit the accepted types to only those.

Add new Rust-based tests

There's a lot going on here.  First, this is intended to run
nicely as part of the new [cosa/kola ext-tests](https://github.com/coreos/coreos-assembler/pull/1252).

With Rust we can get one big static binary that we can upload,
and include a webserver as part of the binary.  This way we don't
need to do the hack of running a container with Python or whatever.

Now, what's even better about Rust for this is that it has macros,
and specifically we are using [commandspec](https://github.com/tcr/commandspec/)
which allows us to "inline" shell script.  I think the macros
could be even better, but this shows how we can intermix
pure Rust code along with using shell safely enough.

We're using my fork of commandspec because the upstream hasn't
merged [a few PRs](https://github.com/tcr/commandspec/pulls?q=is%3Apr+author%3Acgwalters+).

This model is intended to replace *both* some of our
`make check` tests as well.

Oh, and this takes the obvious step of using the Rust OSTree bindings
as part of our tests.  Currently the "commandspec tests" and "API tests"
are separate, but nothing stops us from intermixing them if we wanted.

I haven't yet tried to write destructive tests with this but
I think it will go well.

Merge pull request #2116 from cgwalters/kolainst

tests/kola: Move to tests/kolainst

tests/kola: Move to tests/kolainst

Follow the precedent set in https://github.com/coreos/rpm-ostree/pull/2106
and rename the directory, to more clearly move away from the
"uninstalled" test model.  Prep for Rust-based tests.

Merge pull request #2113 from cgwalters/prepare-root-sysroot-ro

Move ro /sysroot bind mount of /etc into initramfs

Merge pull request #2105 from cgwalters/pull-signapi-explicit

pull: Add support for sign-verify=<list>

Move ro /sysroot bind mount of /etc into initramfs

We recently disabled the read-only /sysroot handling:
https://github.com/ostreedev/ostree/pull/2108/commits/e35b82fb891daee823fcce421ae8f1442b630ea2

The core problem was that a lot of services run early in the
real root and want write access to things like `/var` and `/etc`.

In trying to do remounts while the system is running we introduce
too many race conditions.

Instead, just make the `/etc` bind mount in the initramfs right
after we set up the main root.  This is much more natural really,
and avoids all race conditions since nothing is running in the
sysroot yet.

The main awkward part is that since we're not linking
`ostree-prepare-root` to GLib (yet) we have a hacky parser
for the config file.  But, this is going to be fine I think.

In order to avoid parsing the config twice, pass state from
`ostree-prepare-root` to `ostree-remount` via a file in `/run`.

pull: Add support for sign-verify=<list>

The goal here is to move the code towards a model
where the *client* can explicitly specify which signature types
are acceptable.

We retain support for `sign-verify=true` for backwards compatibility.
But in that configuration, a missing public key is just "no signatures found".

With `sign-verify=ed25519` and no key configured, we can
explicitly say `No keys found for required signapi type ed25519`
which is much, much clearer.

Implementation side, rather than maintaining `gboolean sign_verify` *and*
`GPtrArray sign_verifiers`, just have the array.  If it's `NULL` that means
not to verify.

Note that currently, an explicit list is an OR of signatures, not AND.
In practice...I think most people are going to be using a single entry
anyways.

Merge pull request #2110 from jlebon/pr/fix-admin-tests2

tests/admin-test: Fix --allow-downgrade check

tests/admin-test: Fix --allow-downgrade check

We were doing a check to verify that `ostree admin upgrade` wouldn't
accept a downgrade without `--allow-downgrade`. However, there's no
guarantee that the commit it's upgrading from is older than HEAD^ (what
we're upgrading to). Specifically, if the test runs fast enough, the
timestamps could be equal, since the lowest resolution is seconds.

Rework the test so that we first upgrade to HEAD, which we're sure is at
least 1 second apart from HEAD^, and *then* check that downgrade
protection is enforced.

We also can't use `rev-parse testos/buildmaster/x86_64-runtime` as a way
to know what commit the host is sitting on since the ref might've gone
ahead. Instead, just use `ostree admin status | head -n1`. (I played
with using the `ostree/I/J/K` refs, but those depend on what the
boot/subbootversion is and can easily change if we change previous
tests).

Merge pull request #2111 from strugee/patch-1

Fix typo

Fix typo

Merge pull request #2108 from jlebon/pr/back-out-ro-sysroot

switchroot/remount: Neuter sysroot.readonly for now

switchroot/remount: Neuter sysroot.readonly for now

We're hitting issues with the read-only remounts racing with various
services coming up. Let's neuter it for now until we rework how it
works.

See: https://github.com/coreos/fedora-coreos-tracker/issues/488

Merge pull request #2106 from jlebon/pr/fix-admin-test

tests/admin-test: Ensure that commits are 1s apart

Merge pull request #2107 from cgwalters/more-commit-clocking

admin-test: Show err.txt on unexpected failure

admin-test: Show err.txt on unexpected failure

In a CI run I think one of these `ostree show` commands is failing.
While that output would be useful, the actual `err.txt` usually
has what we want too.

tests/admin-test: Ensure that commits are 1s apart

Otherwise the new check we added there to verify that upgrading without
`--allow-downgrade` fails itself fails.

See: https://github.com/ostreedev/ostree/pull/2099#issuecomment-629805840

Merge pull request #2102 from cgwalters/test-clockskew-check

ci: Test for clock skew

ci: Test for clock skew

I saw `tests/test-admin-deploy.none.sh` fail in one CI run, and
I want to check if it was because of clock skew, so fail
fast if we detect that.

xref https://github.com/ostreedev/ostree/pull/2099#issuecomment-629805375

Merge pull request #2101 from cgwalters/signapi-no-explicit-on

pull: Only have API to disable signapi for local pulls

pull: Only have API to disable signapi for local pulls

There's a lot of historical baggage associated with GPG verification
and `ostree pull` versus `ostree pull-local`.  In particular nowadays,
if you use a `file://` remote things are transparently optimized
to e.g. use reflinks if available.

So for anyone who doesn't trust the "remote" repository, you should
really go through through the regular
`ostree remote add --sign-verify=X file://`
path for example.

Having a mechanism to say "turn on signapi verification" *without*
providing keys goes back into the "global state" debate I brought
up in https://github.com/ostreedev/ostree/issues/2080

It's just much cleaner architecturally if there is exactly one
path to find keys: from a remote config.

So here in contrast to the GPG code, for `pull-local` we explictily
disable signapi validation, and the `ostree_repo_pull()` API just
surfaces flags to disable it, not enable it.

Merge pull request #2100 from cgwalters/make-install-kola-tests

ci: Install kola tests

ci: Install kola tests

This builds on
https://github.com/coreos/coreos-assembler/pull/1441
to install our tests rather than running them from the source
directory.  This model will more cleanly allow us to ship
our tests along with a test container or elsewhere, separate
from the source directory.

Also prep for https://github.com/ostreedev/ostree/pull/2048

Merge pull request #2099 from jlebon/pr/timestamp-check-from-rev

lib/pull: Add `timestamp-check-from-rev`

lib/upgrader: Pull with `timestamp-check-from-rev`

For the same reason as https://github.com/coreos/rpm-ostree/pull/2094.
What we care most about is that the new commit we pull is newer than the
one we're currently sitting on, not necessarily that it's newer than the
branch itself, which it might not be if e.g. we're trying to deploy a
commit older than the tip but still newer than the deployment (via
`--override-commit`).

lib/pull: Add `timestamp-check-from-rev`

The way `timestamp-check` works might be too restrictive in some
situations. Essentially, we need to support the case where users want to
pull an older commit than the current tip, but while still guaranteeing
that it is newer than some even older commit.

This will be used in Fedora CoreOS. For more information see:
https://github.com/coreos/rpm-ostree/pull/2094
https://github.com/coreos/fedora-coreos-tracker/issues/481

Merge pull request #2098 from cgwalters/finalize-requires-mounts

finalize: Add RequiresMountsFor=/boot too

finalize: Add RequiresMountsFor=/boot too

In https://bugzilla.redhat.com/show_bug.cgi?id=1827712
some OpenShift CI is seeing `/boot` being unmounted before
`ostree-finalize-staged.service` runs or completes.

We finally tracked this down to a bug elsewhere, but
I think we should add this because it clearly shows
our requirements.

Merge pull request #2097 from cgwalters/sign-verifier

pull: Further cleanup signapi verification

Merge pull request #2096 from cgwalters/test-staged-delay

tests/staged-delay.sh: New test

pull: Further cleanup signapi verification

Previously in the pull code, every time we went to verify
a commit we would re-initialize an `OstreeSign` instance
of each time, re-parse the remote configuration
and re-load its public keys etc.

In most cases this doesn't matter really because we're
pulling one commit, but if e.g. pulling a commit with
history would get a bit silly.

This changes things so that the pull code initializes the
verifiers once, and reuses them thereafter.

This is continuing towards changing the code to support
explicitly configured verifiers, xref
https://github.com/ostreedev/ostree/issues/2080

tests/staged-delay.sh: New test

Attempting to reproduce
https://bugzilla.redhat.com/show_bug.cgi?id=1827712
but no dice yet.

Merge pull request #2095 from cgwalters/sign-get-all

signing: Change API to create instances directly

signing: Change API to create instances directly

This cleans up the verification code; it was weird how
we'd get the list of known names and then try to create
an instance from it (and throw an error if that failed, which
couldn't happen).

Merge pull request #2092 from cgwalters/sign-verify-ed25519-explicit

remote-add: Add --sign-verify=KEYTYPE=[inline|file]:PUBKEYREF

remote-add: Add --sign-verify=KEYTYPE=[inline|file]:PUBKEYREF

Per https://github.com/ostreedev/ostree/issues/2080#issuecomment-623614483

A huge benefit of ed25519 (and ECC in general) is that keys are very
short - short enough that it's completely reasonable to inline
them into a command line argument.

And I think that's a good model; it makes the keys very visible.

For example, someone could easily copy-paste a commandline
argument from a webpage (secured via TLS) that says to run
`ostree remote add --sign-verify=ed25519=inline:KEY`.

Merge pull request #2093 from cgwalters/sysroot-requires

ostree-prepare-root: Requires=sysroot.mount

ostree-prepare-root: Requires=sysroot.mount

With just `After=` we'll still try to run in the scenario
where `sysroot.mount` fails because the rootfs didn't appear.
And this will end up spewing an error which can confuse people
into thinking something is wrong at the ostree level.

This has come up numerous times w/{Fedora,RHEL} CoreOS, most
recently while looking at
https://bugzilla.redhat.com/show_bug.cgi?id=1803130

Merge pull request #2091 from cgwalters/commit-w-xor-x

commit: Add --mode-ro-executables

commit: Add --mode-ro-executables option

I think we should encourage removing the writable bits from
executables.  This has happened to me:
https://thomask.sdf.org/blog/2019/11/09/take-care-editing-bash-scripts.html

And not having the writable bit may help prevent hardlink
corruption with OSTree in some cases.

We can't do this by default, but add a convenient CLI flag
for it.

Merge pull request #2090 from cgwalters/sign-default-type

signing: Add #define OSTREE_SIGN_NAME_ED25519

signing: Add #define OSTREE_SIGN_NAME_ED25519

Using `#define` or constants instead of strings helps avoid
typos and encourages documentation.

Merge pull request #2089 from dbnicholson/flags-enums-as-bitfields

lib: Coerce flags enums to GIR bitfields

Merge pull request #2087 from cgwalters/test-staged-deploy-cleanup

tests/staged-deploy: Cleanup initial state

lib: Coerce flags enums to GIR bitfields

The GI scanner decides if an `enum` is really a `bitfield` if it finds
any values that have left shifts. With an `enumeration`, the
introspecting language may error or convert to a different type if the
user tries to combine values. Change all Flags `enum`s to use
left-shifted values so that they're represented as `bitfield`s in the
GIR.

The primary bug here is that you can't combine `REFS_ONLY` and
`NO_PRUNE` when calling `OSTree.Repo.prune()` from an introspected
language.

This is an IABI break since the typelib will change from `enumeration`
to `bitfield`. `OstreeRepoImportFlags` is internal but the change is
included here to prepare for a subsequent name that would require bit
shifting to operate correctly as a flag.

tests/staged-deploy: Cleanup initial state

I'm using [cosa build-fast](https://github.com/coreos/coreos-assembler/pull/1371)
and this test doesn't like starting out with two deployments.  Clean
things up to one at the start just to simplify things.

Merge pull request #2084 from d4s/wip/d4s/expose_signapi_metadata

signapi: expose metadata format and key

signapi: expose metadata format and key

Explicitly expose functions for querying the metadata format
and key name used by OstreeSign object:
 - ostree_sign_metadata_format
 - ostree_sign_metadata_key

This allows to use the same metadata format and key name
by 3-rd party applications using signapi.

Signed-off-by: Denis Pynkin <denis.pynkin@collabora.com>

Merge pull request #2083 from agners/doc-updates

Doc updates

docs: extend repository types

Clarify where metadata are stored exactly in the `bare-user` case.
Make the first sentence of `bare-user` and `bare-user-only` paragraph
symetric to make it easier to jump to the right paragraph for readers
in a hury. Stree out that `bare-user-only` may loose metadata.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

docs: extend object type documentation

Extend the object type documentation with file endings used for the
individual type. Also clarify in which situation content type objects
are used and why they do not match the SHA256 hash today.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

docs: clarify archive repo type

Today `archive-z2` is still used as the default string to indicate
a `archive` type repository. Make clear that this is the way it is
intended. Otherwise users might think they use an no longer supported
OSTree repository since the mode string is still `archive-z2`.

Signed-off-by: Stefan Agner <stefan.agner@toradex.com>

Merge pull request #2082 from cgwalters/finalize-sandbox

finalize-staged: Add ProtectHome=yes and ReadOnlyPaths=/etc

Merge pull request #2081 from cgwalters/deploy-etc

deploy: Add --no-merge

finalize-staged: Add ProtectHome=yes and ReadOnlyPaths=/etc

Same motivation as
https://github.com/coreos/rpm-ostree/pull/2060

I tried `InaccessiblePaths=/var` first and was very sad to find
out we have one tiny exception that breaks it.  Otherwise it'd
be so elegant.  Maybe in the future we split out that one thing
to a separate `ostree-finalized-stage-var.service` that's just
`ExecStart=/bin/rm -vf /var/.updated` and is otherwise
`ProtectSystem=strict` etc.

deploy: Add --no-merge

All of the underlying libostree APIs have supported passing `NULL`
for a merge deployment for...a long time.  But we never plumbed
it up into the CLI.

Add a `--no-merge` option to aid people who want to do a "factory reset":
https://github.com/ostreedev/ostree/issues/1793

Merge pull request #2079 from cgwalters/pull-split-sign-verify

 lib: Move gpg/signapi bits into ostree-repo-pull-verify.c

lib: Move gpg/signapi bits into ostree-repo-pull-verify.c

`ostree-repo-pull.c` is huge; separate some of the GPG/signing
verification functions into their own file so they're more easily seen.

lib: Move pull struct definition into repo-pull-private.h

Prep for further splitting up `ostree-repo-pull.c`.

Merge pull request #2077 from jlebon/pr/transaction-cleanup

lib/commit: Check that dirent is a directory before cleaning

lib/commit: Check that dirent is a directory before cleaning

I've only noticed this by inspection. But I think it's possible for
`cleanup_txn_dir` to get called with the `staging-...-lock` file since
it matches the prefix.

Make the checking here stronger by verifying that it's a directory. If
it's not a directory (lockfile), then follow the default pruning expiry
logic so that we still cleanup stray lockfiles eventually.

lib: Rename function for staging dir check

Rename the function to more accurately reflect what it does, which is to
check whether the filename has the `staging-` prefix.

lib/commit: Add more error prefixing

We think we're hitting an error in that function in the Fedora infra.
Add some more error prefixing to help debugging.

Merge pull request #2076 from d4s/wip/d4s/rename_with-libsodium_opt

sign: rename option for enabling ed25519